複数のミドルウェア環境全体のメッセージフローのサービス品質（ｑｏｓ）管理

专利摘要:
複数の相互接続ミドルウェアドメイン内及び全体に、一貫したサービス品質レベル「ＱｏＳ」を有するメッセージフローを提供するための、情報システム・リソースを管理する方法は、少なくとも１つのＱｏＳ要件を表示し、少なくとも１つのＱｏＳ要件を、複数のミドルウェアドメイン（４０４、４０６）を通信可能に連結するメッセージサービス（４３２）に特有の少なくとも１つのパラメータに変換し、メッセージフローを受信するために、第１ミドルウェアドメイン（４０４）とメッセージサービスとの間にクライアント接続を作成し、ＱｏＳメッセージを第２ミドルウェアドメイン（４０６）へ伝達し、メッセージフローを伝達するために、メッセージサービスと第２ミドルウェアドメインとの間にクライアント接続を作成する第１ＱｏＳマネージャ（４２６、５６４）からＱｏＳメッセージを受信することを含む。
公开号:JP2011505613A
申请号:JP2010533169
申请日:2008-10-31
公开日:2011-02-24
发明作者:ロバート；ジェイ． ウィニッグ，；ロドルフォ；エー． サンティアゴ，；アリス チェン，；グイジュン ワン，；チャンホウ ワン，
申请人:ザ・ボーイング・カンパニーＴｈｅ Ｂｏｅｉｎｇ Ｃｏｍｐａｎｙ；
IPC主号:G06F13-00

专利说明:

[0001] 本発明は概して情報システムに関し、さらに具体的には、複数のミドルウェア環境を含む情報システムにおけるサービス品質（ＱｏＳ）管理に関するものである。]
背景技術

[0002] ＱｏＳ管理は、複数の並列ネットワーク・アプリケーションによってシステム・リソースの使用を最適化するために、ネットワーク化された情報管理システムにおいて実行可能である。情報管理システムにおける作業の単位は一般に、タスク又はメッセージのいずれかと見なすことができる。オブジェクト指向システムにおいては、プリミティブタスクは例えば、あるオブジェクトの実行スレッドであってよい。メッセージは通常、様々な種類の情報のカプセル化機能である。システムはタスク指向又はメッセージ指向になりがちである。したがって、公知のＱｏＳ管理方法はタスク指向又はメッセージ指向のいずれかとなる傾向がある。]
[0003] タスク指向システムとメッセージ指向システムのＱｏＳ管理概念及びフレームワークは似ている可能性があるが、実際の実装技術は全く異なったものになりがちである。タスク指向システムにおいては、ＱｏＳ管理技術は通常、アプリケーションのＱｏＳ要件を満たすために、タスク実行を優先させることに重点を置く。メッセージ指向システムにおいては、ＱｏＳ管理技術は通常、メッセージの受信、処理、及び配信の品質に重点を置いている。例えば動作及び信頼性等の品質特性の意味が、タスク指向システムのそれとは若干異なる可能性がある。例えば、メッセージの信頼性は通常、配信の保証、メッセージの順序付け、及び複製の除去の組み合わせを意味する。タスクの信頼性はその一方で、通常失敗せずにタスクを良好に実行できる可能性を意味する。]
[0004] ＱｏＳ管理はタスク指向システムにおいて、分散された環境でタイミングよく優先度の高いタスクを終わらせるために計算的応用をサポートするのに現在使用されている。しかしながら、メッセージ指向情報管理システムのＱｏＳ管理はあまり注目されてこなかった。上記システムは、サービス指向アーキテクチャ（ＳＯＡ）が実行される情報管理システムを含む。ＳＯＡは例えば、発行／購読、オブジェクト・リクエスト・ブローカー、ピアツーピアアーキテクチャ又はこれらの組み合わせであってよい。]
[0005] 発行／購読アーキテクチャにおいては、情報ブローカーにより、システムのクライアントアプリケーションに対するサービスが提供される。情報ブローカーは、分散された情報管理システム及びネットワーク中央軍事システムにおける情報の発行、処理、及び普及において中心的な役割を果たす。ブローカーシステムの例には、電子メール、情報圏、コラボレーション、仮想コミュニティ、及びグループ通信が含まれる。多数の並列クライアントとそれらの要求がシステム・リソースを争うため、ブローカーシステムが重要なクライアントの要求を満たすことが容易でない可能性がある。公知の情報ブローカーのリソース管理方法では、異なるＱｏＳ特性を有するクライアント同士を区別して、システム・リソースを、複数のミドルウェアドメイン全体においてであっても、これに沿って管理するようにはできない。]
[0006] 本発明の様々な実施形態は、複数の及び異なったメッセージ指向ミドルウェア（ＭＯＭ）環境又はドメイン内及び全体のメッセージフローに、一貫したポリシー主導型サービス品質（ＱｏＳ）要件を適用することによって、上述の確認された欠陥、その他に対処することができる。]
[0007] 一実施形態では、複数のミドルウェアドメイン内及び全体の一貫したサービス品質（ＱｏＳ）レベルを有するメッセージフローを提供するための、情報システム・リソースの管理方法が記載されている。本方法は、少なくとも１つのＱｏＳ要件を表示し、少なくとも１つのＱｏＳ要件を、複数のミドルウェアドメインを通信可能に連結するメッセージサービスに特有の少なくとも１つのパラメータに変換し、メッセージフローを受信するために、第１ミドルウェアドメインとメッセージサービスとの間にクライアント接続を作成し、ＱｏＳメッセージを第２ミドルウェアドメインへ送信し、メッセージフローを送信するために、メッセージサービスと第２ミドルウェアドメインとの間にクライアント接続を作成する第１ＱｏＳマネージャからＱｏＳメッセージを受信することを含む。]
[0008] 別の実施形態では、複数の相互接続ミドルウェアドメイン内及び全体で一貫したＱｏＳレベルを有する、メッセージフローを提供するサービス品質（ＱｏＳ）ブリッジが説明されている。第１ＱｏＳマネージャから少なくとも１つのＱｏＳ要件を受信するＱｏＳブリッジは、第２ＱｏＳマネージャへ少なくとも１つのＱｏＳ要件を伝え、少なくとも１つのＱｏＳ要件を少なくとも１つのＱｏＳパラメータへ変換する。ＱｏＳブリッジはまた、メッセージサービスを用いて少なくとも１つのＱｏＳパラメータを受信し実施して、複数の相互接続ミドルウェアドメイン間のメッセージフローを容易にする。]
[0009] さらに別の実施形態では、少なくとも１つのプロセッサによって実行される少なくとも１つの第１ミドルウェアソリューション及び第２ミドルウェアソリューションを含む情報システムにおいてＱｏＳを管理するためのサービス品質（ＱｏＳ）管理システムが記載されている。ＱｏＳ管理システムは、少なくとも１つのＱｏＳパラメータを表すＱｏＳメッセージが情報システムのクライアントから受信されるように、少なくとも１つのプロセッサで実行される第１ＱｏＳマネージャ、第１ＱｏＳマネージャからＱｏＳメッセージが受信されるように、少なくとも１つのプロセッサで実行されるＱｏＳブリッジ、及びＱｏＳブリッジからのＱｏＳメッセージが第２ＱｏＳマネージャによって受信され、情報システムのサブスクライバに送られるように、少なくとも１つのプロセッサに実装される第２ＱｏＳマネージャを含む。]
図面の簡単な説明

[0010] 図１はサービス指向アーキテクチャ（ＳＯＡ）を有する例示の情報システムの図である。
図２はＱｏＳ管理アーキテクチャの例示の実施形態の図である。
図３は複数のミドルウェアドメインを含む例示の情報システムの図である。
図４は図３の情報システムの応用の例示の実施形態の図である。用語は本明細書では、一例を例示するものであり、必ずしも理想的なものではない。] 図１ 図２ 図３ 図４
実施例

[0011] 次の説明は単なる例示であり、決して応用又は使用を限定するものではない。パブリッシャ／サブスクライバ情報管理サービス指向アーキテクチャ（ＳＯＡ）を参照して一又は複数の構成が記載されているが、構成はこれに限定されない。他の種類の情報システムに関連して、非限定的に他の及び追加の種類のサービス指向アーキテクチャ、情報管理システム及び／又はネットワークシステムを含む、他の及び追加的な構成が考えられる。]
[0012] 一般に、サービス指向アーキテクチャ（ＳＯＡ）を有するシステムは、サービスの集合組成として扱うことができる。各サービスは、明確に定義されたインターフェースを介してその機能性を利用可能にすることができる。ＳＯＡでは、各サービスは通常、自己記述的であり、オープンソフトウェアコンポーネントである。ＳＯＡは、サービスと、これらの組成及び相互作用を含む。システムのクライアントに対して情報システムのリソースを管理する方法が下に記載されている。情報システムのリソースを管理する例示の方法は、米国特許出願公開第２００５／０２０４０５４号明細書にも記載されている。]
[0013] 図１はＳＯＡを実行する情報システム２０の図である。この実施形態においては、情報システム２０はパブリッシャ／サブスクライバＳＯＡを有する。パブリッシャ２４は、例えば特定のテーマのメッセージを購読している関心のある当事者によって操作される、例えば複数のテーマ及びサブスクライバ３４においてメッセージを発行する。図の形態で示されているが、一又は複数の要素は、コンピュータプロセッサ、付随メモリ、及び関連のハードウェアを含み、プロセッサは本明細書に記載された方法、装置、又はシステムに対応する一又は複数の操作を実行するために、コンピュータの指示をフェッチし、デコードし実行することが分かっている。このように、コンピュータが読み取り可能な又は機械が読み取り可能な媒体をプロセッサで使用して、指示を与えることができる。コンピュータが読み取り可能な媒体は、コンパクトディスク（ＣＤ）、フロッピー（登録商標）又はハードディスク等の磁気媒体、又はランダム・アクセス・メモリ（ＲＡＭ）又は読取専用メモリ（ＲＯＭ）等のソリッドステートメモリ等の光媒体を含むことができる。] 図１
[0014] 発行サービス３８及び購読サービス４２は情報ブローカー（ＩｎｆｏＢｒｏｋｅｒ）４６を通して分離される。パブリッシャ２４及びサブスクライバ３４は、サービスプロバイダとしてのＩｎｆｏＢｒｏｋｅｒ４６に対するサービスリクエスター（本明細書では「クライアント」及び「アプリケーション」とも称される）である。発行サービス３８及び購読サービス４２は、ＩｎｆｏＢｒｏｋｅｒ４６によってパブリッシャ２４及びサブスクライバ３４へ提供される共通サービス５０に含まれる。共通サービス５０はまた、セキュリティ５４、パーシスタンス５６、フィルタリング５８、融合６０、配布６２、及びディスカバリ６４も含む。購読登録等の追加のサービス６６も提供可能である。情報ブローカー４６はまた、共通サービス５０としてクライアント２４及び３４にＱｏＳ管理サービス７０を提供する。情報ブローカー４６は、さらに下に記載するように、それを通してクライアントがＱｏＳ規約について交渉することができるＱｏＳマネージャ７４へのアクセスを提供する。情報ブローカー４６は、さらに下に記載するように、ＱｏＳ管理サービス７０を介してクライアント２４及び３４へサービス品質を提供する。]
[0015] ある実施形態では、パブリッシャ２４及びサブスクライバ３４がＩｎｆｏＢｒｏｋｅｒ４６を同時に発見し、前記サービス５０を使用することができる。上記サービスは異なるＱｏＳ特性を有することができ、上記サービスの相互作用は同時で、分断可能である。異なるパブリッシャ２４及びサブスクライバ３４は、動作、信頼性、適時性、及び安全性の点において異なるＱｏＳ要件を有することができる。例えば、あるパブリッシャ２４は他のパブリッシャよりも高い優先度を有することができ、メッセージがより早い応答時間において正確な順序付けで配信される保証が要求される可能性がある。同様に、あるサブスクライバ３４は他のサブスクライバよりもさらに緊急性を有する可能性があるため、メッセージの受信における遅延がより短いことが要求される。]
[0016] サービスプロバイダとしてのＩｎｆｏＢｒｏｋｅｒ４６は、一又は複数のＱｏＳ保証を一又は複数のパブリッシャ２４及び／又はサブスクライバ３４へ提供することができる。ＩｎｆｏＢｒｏｋｅｒ４６は、例えば時間単位当たりのメッセージの受信又は配信速度、及び／又はメッセージのペイロードサイズ等のパブリッシャ２４及び／又はサブスクライバ３４の一又は複数の動作を制限することができる。パブリッシャ２４及びサブスクライバ３４等の複数の並列クライアントのＱｏＳ要件を満たすために、ＱｏＳ管理サービス７０は、アドミッションコントロール８０、予測８２、リソース管理８４、監視８６、及び適合８８等の上記サービスを含む。]
[0017] パブリッシャ２４及びサブスクライバ３４は、ＩｎｆｏＢｒｏｋｅｒ４６にＱｏＳ要件を表示して、ＱｏＳ規約について交渉することができる。ＱｏＳ規約は一時的又は恒久的であってよい。このように、ＱｏＳ規約は特定の役割を持つクライアントに対してセッション基準ごとの一時的なもの又は恒久的なものであってよい。ＩｎｆｏＢｒｏｋｅｒ４６は、クライアントとのＱｏＳ規約を満たすためのリソース及び機構を提供する。ＩｎｆｏＢｒｏｋｅｒ４６は、ＱｏＳ規約の実行中にシステムの状態を監視し、適切な適合サービスを提供する。]
[0018] ある構成においては、ＩｎｆｏＢｒｏｋｅｒ４６がＱｏＳマネージャ７４をエクスポートして、そのＱｏＳ管理サービス７０をクライアントが利用可能にする。クライアント２４及び／又は３４は、拡張可能なマークアップ言語（ＸＭＬ）メッセージとしてＱｏＳ要件をＱｏＳマネージャ７４へ送る。承認済みのＱｏＳ規約を受信するにあたって、クライアントは規約をＩｎｆｏＢｒｏｋｅｒ４６との相互作用（例：メッセージの送信及び／又は受信）に対する背景として使用する。]
[0019] 図１に例示されたアーキテクチャは、ＱｏＳサービスプロバイダとしてのＩｎｆｏＢｒｏｋｅｒ４６のＱｏＳ管理の複数の態様を包含するコンポーネントサービスを提供する。例えば、ＩｎｆｏＢｒｏｋｅｒ４６は、アプリケーションのＱｏＳ要件を分析することができ、ポリシーだけでなく、現在の及び予測される今後のシステムの状態に基づいてアドミッションコントロールの決定を行うことができる。ＩｎｆｏＢｒｏｋｅｒ４６は、システム・リソース及び機構をＱｏＳ要件を満たすようにすることができ、システムの動作をランタイムにおいて監視し、適応させることができる。] 図１
[0020] 一般に、情報システム２０においては、サービス５０のＱｏＳ要件はＱｏＳ特性の観点から指定される。ＱｏＳ特性は、サービスリクエスターとサービスプロバイダの両方によって理解されている明確な態様又は制限事項を表す。ＱｏＳ特性は、例えば４つのカテゴリー：動作、信頼性、適時性、及び安全性に分類できる。一連のＱｏＳパラメータは、例えば下記のように各カテゴリーに関連することができる。動作カテゴリー関連は：応答時間、メッセージスループット、ペイロードサイズ、発行／購読ボリュームレート、及びエンド・エンド遅延である。信頼性カテゴリー関連は：配信保証、複製除去、メッセージの順序付け、呼損率、エラー率、再試行スレッショルド、メッセージの継続性及びクリティカリティである。適時性カテゴリー関連は：生存時間（ＴＴＬ）、期限、一定のビットレート、フレームレート、及び優先度である。安全性カテゴリー関連は：メッセージ署名付与、及び暗号化である。]
[0021] 前述したＱｏＳ特性及びパラメータの分類は、例示であることに注目すべきである。ＱｏＳの態様の他の及び／又は追加の特徴づけ及び／又は分類が考えられる。ある例示の実施形態では、前述したＱｏＳ特性及びパラメータの分類に基づいて、ＳＭＬをベースにした言語により、サービスリクエスターが一又は複数のＱｏＳ要件をＱｏＳメッセージとして表すことができる。]
[0022] 図２は、例示のＱｏＳ管理アーキテクチャ３００の図である。ＱｏＳ管理アーキテクチャ３００は、コンポーネントサービス、コンポーネントサービスの相互作用、及び、例えば商用オフザシェルフ（ＣＯＴＳ）監視ツールを介した、リアルタイムホスト及びネットワークの状態監視等の外部サービスとのインターフェースを含むことができる。主要なコンポーネントサービスは、ＱｏＳマネージャ３０８、設定サービス３１２、ポリシーマネージャ３１６、リソースマネージャ３２０、予測サービス３２４、オペレーションサービス３２８、メンテナンスサービス３３２、監視サービス３３６、適応サービス３４０、及び診断サービス３４４を含む。監視サービスとＱｏＳ診断サービスの間の相互作用３４８は、登録及び通知スタイルに従う一方、他のサービス間の相互作用３５２は、要求及び応答スタイルに基づいている。さらに下に説明されるように、診断サービス３４４は、ＣＯＴＳ監視ツール３６４を介したリアルタイムホスト３５６とネットワーク３６０等の外部サービスとインターフェースで接続する。] 図２
[0023] ＱｏＳマネージャ３０８は、クライアントのＱｏＳサービスの設定及び操作を調整する。ＱｏＳマネージャ３０８は、図１を参照しながら前述したように、クライアントがＱｏＳ管理サービスにアクセスするためのインターフェースを提供する。設定サービス３１２は、さらに下に説明するように、ＸＭＬＱｏＳメッセージで表されるＱｏＳ要件を前提としたクライアントのＱｏＳ規約を設定することができる。設定サービス３１２はまた、さらに下に説明するように、ポリシーマネージャ３１６、予測サービス３２４、及びリソースマネージャ３２０を使用する。規約が設定できない場合、設定サービス３１２は、クライアントに代わって設定要求を行ったＱｏＳマネージャ３０８へ報告する。] 図１
[0024] ポリシーマネージャ３１６はＱｏＳポリシー３６８をチェックして、クライアントのＱｏＳ要件のパラメータが確実にクライアントの役割に対して許可されるようにし、許可された場合は、要件を満たすためにどのリソース及び機構が必要かをチェックする。リソースマネージャ３２０は、システム・リソースのリザベーション、アロケーション、及びリリースを含むリソースのライフサイクル管理を提供する。リソースは通常ホスト３５６のプラットホームに対してローカルであるため、リソースマネージャ３２０は一般のＱｏＳ管理機能の抽象クラスを定義する。プラットホームの例は、オブジェクト・マネージメント・グループによるコモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ（ＣＯＲＢＡ）、カリフォルニア州サンタクララのサンマイクロシステム社によるジャバ・プラットフォーム・エンタープライズ・エディション（Ｊ２ＥＥ）、及びワシントン州レッドモンドのマイクロソフト社による、ドットネットフレームワークである。具体的なリソースクラスは、さらに下に説明するように、各ホストプラットホームに対して実行される。]
[0025] 予測サービス３２４は、幾つかの主要なシステムパラメータ（例：メモリの使用量、ＣＰＵロード、ネットワークスループット、遅延）の観点から、システムの状態を追跡する。予測サービス３２４はまた要求に応じて、様々な予測アルゴリズムを使用して短い時間の制限枠において今後のシステム状況も予測する。]
[0026] オペレーションサービス３２８は、初期設定プロセス３３０を使用してＱｏＳ規約のリソース構成を初期化して、ＱｏＳ規約の実行中にサービスを調整する。メンテナンスサービス３３２は、ＱｏＳ規約の一又は複数の主要なＱｏＳパラメータを保持することができ、上記パラメータに対するスレッショルドの交差に応じて適合サービス３４０を起動することができる。監視サービス３３６は、リソースの利用及び有効性のレベルをサンプリングし統合して、実際のスループット及び遅延値等の動作を測定する。監視サービス３３６は、例えばシステムの状態の変化に起因して、予測が本当になった時に、通知を返信する、診断サービス３４４による状態予測を登録する。]
[0027] 適合サービス３４０はリソースと機構３７２を動的に変えて、主要なＱｏＳパラメータを正常な範囲内に戻す。適合サービス３４０はまた、クライアントによる規約の違反に応じて操作を行うことができる。上記操作は例えば、承認された発行日をはるかに越えて発行するクライアントからのメッセージの受信を遅らせることを含むことができる。例えば、実際のパラメータがそのスレッショルド値よりも下に戻ると、メンテナンスサービス３３２は適合サービス３４０にＱｏＳ規約に従ってＱｏＳレベルを戻すように要求することができる。適合機構３７２は、プラグインであってよい。したがって、適切な適合機構３７２をポリシーに基づいて静的に構成し、動的に選択することが可能である。]
[0028] 診断サービス３４４は、因果ネットワークを使用して低レベルのシステム信号をシステムの状態のアトリビュートに統合する等の、推論技術を採用する。診断サービス３４４は、監視ツール３６４からリアルタイム入力を取得して、データをオンダフライで統合し、データを保存場所３７６に保存する。診断サービス３４４はまた、値の変化に応じてアトリビュートの述語全てを評価して、例えば監視サービス３３６等の関与サービスへの通知をトリガーすることもできる。]
[0029] クライアントはＱｏＳサービスプロバイダ（例：図１を参照して説明されたような情報ブローカー）にクエリを行うことによって、又はディスカバリサービスを使用することによって、ＱｏＳマネージャ３０８を通してＱｏＳ管理サービスにアクセスする。例示の実施形態では、ＱｏＳマネージャ３０８は、クライアントがＱｏＳサービスと直接接点を持つＱｏＳ管理アーキテクチャ３００における唯一のコンポーネントである。] 図１
[0030] ミドルウェアドメインは、ミドルウェアソリューションがクライアントアプリケーションの集合体にサービスを提供する、１つの管理ドメインを有する環境である。ミドルウェアドメインの例には、アパッチソフトウェア財団によるＡｃｔｉｖｅＭＱメッセージブローカー、ＪＢｏｓｓアプリケーションサーバー、ニューヨーク州アーモンク市のＩＢＭ社によるウェブスフィア、データ配信サービス（ＤＤＳ）、イリノイ州シカゴのボーイング社によるシステムのシステム共通オペレーティング環境（ＳＯＳＣＯＥ）、及びＣＯＲＢＡが含まれる。情報システム２０に関して記載したように、ＱｏＳサポートを保持しながら、メッセージを１つのミドルウェアドメインから別のミドルウェアドメインへ発信することができれば有利である。]
[0031] 図３は例えばミドルウェアドメイン４０４とミドルウェアドメイン４０６等の複数のミドルウェアドメインを含む情報システム４００を介したメッセージフローの図である。メッセージフローは点線で表されており、制御フローとも称される規約交渉は実線で表されている。例示の実施形態では、情報システム４００は発行／購読ＳＯＡの実現である。パブリッシャ４０８は例えば複数のテーマのメッセージを発行し、サブスクライバ４１０は例えば特定のテーマのメッセージを購読している関心のある当事者によって操作される。複数のＱｏＳマネージャ４２６及び４２８によって、クライアントのＱｏＳサービスの設定及び操作が調整される。ＱｏＳマネージャ４２６及び４２８により、図１を参照して前述したように、ＱｏＳ管理サービスへアクセスするためのクライアント向けのインターフェースが提供される。情報システム４００はまた、ＱｏＳアトリビュートを保持しながら、パブリッシャ４０８からサブスクライバ４１０までの複数のミドルウェアドメイン全体のエンド・エンドメッセージフローを容易にするために、ＱｏＳブリッジ４３０及びメッセージサービス４３２も含む。] 図１ 図３
[0032] 上述したように、ＱｏＳは例えば情報システム４００等のシステムの、異なる優先レベルにおいて、例えばパブリッシャ４０８及びサブスクライバ４１０等のクライアントへサービスを提供する能力を参照する。メッセージ指向システムについては、ＱｏＳはクライアント、ミドルウェア、及びネットワークによるメッセージのトランスポート及び処理への異なる動作レベルの割当てを参照する。ＱｏＳ管理は、例えば非限定的に、スループット、レーテンシ、ジッター（タイミングの不一致）、損失、耐久性、持続性等のＱｏＳアトリビュートのセットアップ及び制御に関わっている。ＱｏＳ要件及びＱｏＳ規約はこれらのアトリビュートの集合体である。ＱｏＳ要件により、アプリケーションによって要求されたメッセージング動作レベルが指定され、ＱｏＳ規約により、アプリケーションに与えられた（すなわち「約束された」）動作レベルが指定される。さらに例示の実施形態では、ＱｏＳ要件が全く指定されない場合、ＱｏＳ要件のデフォルト設定が暗示される。例えば、ＱｏＳ要件のデフォルト設定には、「有望な」ベストエフォート型を含むことができる。]
[0033] エンド・エンドメッセージフローは、例えばパブリッシャ４０８等の発行元におけるメッセージの生成から開始し、例えばサブスクライバ４１０等の顧客によるメッセージの消費で終了する。複数の異機種環境のミドルウェアドメインから出来たシステムでは、エンド・エンドメッセージフローにはまた、ミドルウェアソリューション間、及び全てのミドルウェアソリューション内部のトランスポートが含まれる。ＱｏＳアトリビュートの保持は、リアルタイムのミッションクリティカルな環境の基礎コンポーネントである。システムのエンドポイントだけでなく、メッセージを処理する中継体は、サービスのニーズを指定するＱｏＳ規約を順守するものでなければならない。通常、公知のミドルウェア技術により、ある程度のＱｏＳサポートが提供される。しかしながら、ＱｏＳサポートレベルは技術によって、フロー間の相対的な優先順位から、例えばトラフィック・シェーピング及びデータの持続性等の概念まで変化する。]
[0034] ＱｏＳブリッジ４３０により、ミドルウェアソリューション４０４及び４０６がそれぞれのクライアントアプリケーションに設定されたＱｏＳ規約を共有することが可能になり、これにより、異なるミドルウェアドメインのアプリケーション間のメッセージフローに、複数の相互接続ミドルウェア環境又はドメイン内及び全体で一貫したＱｏＳレベルが与えられる。ＱｏＳブリッジ４３０を介して設定されたＱｏＳ規約を伝播（すなわち、送信及び受信）するために、ミドルウェアドメイン４０４及び４０６それぞれのＱｏＳマネージャ４２６及び４２８によって、特定のプロトコル（図３に図示せず）が使用される。プロトコルは、異なるミドルウェアドメインへメッセージを送信する時に、１つのミドルウェアドメインのパブリッシャに設定された規約のＱｏＳ設定をＱｏＳ要件として使用できるように、ＱｏＳマネージャ４２６及び４２８によって使用される。例えば、パブリッシャ４０８及びＱｏＳマネージャ４２６間に設定された規約をＱｏＳブリッジ４３０からＱｏＳマネージャ４２８へ送られたＱｏＳ要件として使用することができる。] 図３
[0035] ＱｏＳマネージャ４２６は、例えばパブリッシャ４０８等のアプリケーションをそのドメインに有するＱｏＳ規約のセットアップ及びメンテナンスに関与する。ＱｏＳマネージャ４２６はパブリッシャ４０８からＱｏＳ要件を受信し、ＱｏＳポリシー４４６及び利用可能なリソースによって指示される規約を提示する。パブリッシャ４０８によって受け入れられた時に、規約は拘束力を持つ。ＱｏＳマネージャ４２６は、ＱｏＳ規約をミドルウェアドメイン４０４に特有の一連のＱｏＳパラメータに変換し、一連のＱｏＳパラメータとパブリッシャ４０８とを関連付けることによって、規約を適用する。例えば、パブリッシャ４０８がＱｏＳ規約を受け入れると、ＱｏＳマネージャ４２６はミドルウェアのパブリッシャ４０８への接続を作成して、この接続部にＱｏＳパラメータを設定する。]
[0036] ＱｏＳマネージャ４２６はまた、ＱｏＳ要件をＱｏＳブリッジ４３０へ送信し、ＱｏＳブリッジは次に、ＱｏＳ要件を例えばミドルウェアドメイン４０６等のほかのミドルウェアドメインへ伝播させる。ＱｏＳブリッジ４３０は特化したＱｏＳマネージャである。さらに具体的には、ＱｏＳブリッジ４３０はミドルウェアドメイン間のＱｏＳマネージャである。クライアントアプリケーション及びミドルウェアソリューションと相互作用する代わりに、ＱｏＳブリッジ４３０は例えば、ＱｏＳマネージャ４２６及びメッセージサービス４３２等のＱｏＳマネージャ及びメッセージサービスと相互作用する。メッセージサービス４３２は、ＱｏＳマネージャ４２６及びＱｏＳブリッジ４３０との間に設定された各メッセージフローのＱｏＳ設定を実行することを含む、２つ以上のミドルウェアドメイン間の相互運用性を提供する。例示の実施形態では、明確なＱｏＳ要件なしに、メッセージサービス４３２に到着するメッセージフローは例えば、ベストエフォート型の方法を保証する一連のＱｏＳ要件等のＱｏＳ要件のデフォルト設定と関連するように扱われる。]
[0037] 複数のミドルウェアドメイン全体のエンド・エンド通信の実例となる方法もまた図３に示されている。パブリッシャタイプのクライアントアプリケーション４０８は、そのＱｏＳ要件をＱｏＳマネージャ４２６に提示することによってメッセージフローを開始する５００。ＱｏＳ要件はミドルウェア独立言語で書かれている。ＱｏＳマネージャ４２６は、受信したＱｏＳ要件、ＱｏＳポリシー４４６、及び利用可能なリソースに基づいて、ミドルウェア独立ＱｏＳ規約を作成する５０２。一意識別子は規約と関連付けられている。ＱｏＳ規約はさらに、ＱｏＳ要件、オペレータルール、コンテンツタイプのユーザアカウント、利用可能なコンピューティングリソース（ローカル及び／又はリモート）、及び利用可能なネットワークリソースにのみ基づくように限定されないが、これらに基づいたものであってよい。] 図３
[0038] ＱｏＳマネージャ４２６は、ミドルウェア独立ＱｏＳ規約をミドルウェア特有のリソースプランへ変換する５０８。リソースプランは規約を満たすのに必要なコンピューティングレベルとネットワークリソースを含んでいる。ＱｏＳ規約はパブリッシャ４０８へ送られ５１２、パブリッシャ４０８は規約を受信する。パブリッシャ４０８は受入れメッセージをＱｏＳマネージャ４２６へ発信し５１６、メッセージフローへのメッセージの発行を開始する５１８。]
[0039] ＱｏＳマネージャ４２６はリソースプランを実行する５２２。リソースプランにおいて呼び出されたコンピューティング及びネットワークリソースは、メッセージフローに割り当てられる。例示の実施形態では、リソースプランとＱｏＳ規約は下記：バッファメモリ等のコンピューティングリソース及び緊急優先事項のフローサービスの専用スレッドの割当てを決定する、プロセス及びスレッド優先度を設定する、ネットワークパケットを例えば適切なＤｉｆｆＳｅｒｖコードポイントでマーキングするうちの少なくとも１つに使用される。]
[0040] ＱｏＳマネージャ４２６はＱｏＳ要件をＱｏＳブリッジ４３０へ伝達する５２４。ＱｏＳブリッジ４３０は、ソースミドルウェアドメイン（すなわち、発行元）から受信したＱｏＳ要件を取得して、メッセージサービス４３２と相互作用して５２８、メッセージフローを受信するために、発信元のミドルウェアドメインとのクライアント接続を作成する。ＱｏＳブリッジはまた、ブリッジポリシー５３０を使用して受信したＱｏＳ要件を、ミドルウェアドメイン４０４と４０６を接続するメッセージサービス４３２特有の一連のＱｏＳパラメータに変換する。ＱｏＳブリッジ４３０はまた、受信したメッセージフローのＱｏＳ要件をそのままの状態の下流のミドルウェアドメイン４０６へ、あるいは、ブリッジポリシー５３０にしたがって修正された下流のミドルウェアドメイン４０６へ伝達する。]
[0041] 送信先のミドルウェアドメイン４０６のＱｏＳマネージャ４２８は、上述したように、発信元のＱｏＳマネージャ４２６と同じステップを行う。言い換えると、ＱｏＳマネージャ４２８は、「ローカル」ＱｏＳ規約及び同等のリソースプランを作成し５３４、リソースをリザーブし、規約をクライアント（この場合はＱｏＳブリッジ４３０）へ送り、受入れに応じてリソースプランを実行する。]
[0042] 例えばサブスクライバ４１０等のクライアントアプリケーションは、それぞれのミドルウェア４０６でメッセージフローを購読する５３６。このステップは他の制御フロー通信とは独立しているため、この購読を任意の時点で行うことができる。]
[0043] 代替実施形態では、パブリッシャ４０８からのＱｏＳ要件の代わりに、パブリッシャ４０８とＱｏＳマネージャ４２６の間の適所にあるＱｏＳ規約が、ＱｏＳマネージャ４２６とＱｏＳブリッジ４３０の間に伝達される５２４。ソースドメイン４０４においてＱｏＳマネージャ４２６によって与えられたものが、パブリッシャ４０８によって要求されたＱｏＳレベルよりも大幅に低い状況にある制御フローにおいては、下流のドメイン４０６が最初の要件で要求されたリソースレベルをリザーブすることは役に立たない。最初のＱｏＳ要件の代わりにＱｏＳ規約を伝達することによって、不必要で煩わしいリソースリザーブを回避することができる。]
[0044] 図４は上述した情報システム４００の応用の例示の実施形態の図である。図４は、複数のミドルウェアドメイン全体のメッセージフローにポリシー駆動型ＱｏＳを適用するための情報システム５４８を示す。例示の実施形態では、ＪＢｏｓｓミドルウェア５５２をホストとしたレガシーシステムのクライアントアプリケーション５５０は、ＳＯＳＣＯＥミドルウェア５５６をホストとした進歩したシステムのクライアントアプリケーション５５４と情報を共有する必要がある。サービスブローカー５６０は、クライアントアプリケーション５５０とミドルウェアプラットホーム５５２との間の媒介として作用する。サービスブローカー５６２は、ミドルウェアプラットホーム５５６の代わりに、クライアントアプリケーション５５４に対して同じ機能を発揮する。サービスブローカー５６０は、ＱｏＳマネージャ５６４を含み、サービスブローカー５６２はＱｏＳマネージャ５６６を含む。ＱｏＳブリッジ５７０により、ミドルウェアドメイン５５２からのメッセージをミドルウェアドメイン５５６と共有することが可能になる。ＱｏＳブリッジ５７０は、ＱｏＳマネージャ５６４からメッセージフローのＱｏＳ要件を受信する特定のタイプのＱｏＳマネージャであり、ＱｏＳマネージャ５６６とともに機能して、継続する同じメッセージフローに同じ一連のＱｏＳ要件を適用する。] 図４
[0045] 進歩したシステム、レガシーシステム、及びデータベースシステムは、様々なミドルウェアドメインにおいて操作可能なシステムの例である。サービスブローカー５６０及び５６２は、ミドルウェア特有のシステムとミドルウェアから独立したシステムの間で変換を行う。さらに、サービスブローカー５６０及び５６２は、これらのシステムが本物であることを証明し、これらのサービスのニーズを許可し管理する。サービスブローカー５６０及び５６２はまた、メッセージの優先順位付けが関連のミドルウェアプラットホームからなされない場合に、設定されたＱｏＳ規約にしたがってメッセージフローの個々のメッセージの送信の優先順位付けもすることができる。]
[0046] 上述した実施形態により、異なるミドルウェアソリューション間のメッセージングを可能にする効果的なエンド・エンドＱｏＳ管理アーキテクチャが提供される。サービスブローカー及びＱｏＳブリッジのＱｏＳマネージャは、ＱｏＳ要件を適切なミドルウェア特有のターゲットフォーマットへ変換して必要なリソースのアロケーションを提供して、予測可能な適応できる保証されたメッセージ配信及びプライオリティルーティングをサポートする。]
[0047] 上述した方法及びシステムにより、ＱｏＳ要件／規約によってエンドポイントからエンドポイントへの全てのメッセージフローの処理を指定することが可能になる。ＱｏＳ規約はミドルウェアドメイン及び中継（ブリッジ）ノードによって一貫して施行される。ＱｏＳポリシーは再定義することができ、ＱｏＳ要件からのＱｏＳ規約の設定の制御、ＱｏＳ要件／規約のミドルウェア特有のリソースプランへの変換、及びＱｏＳ要件／規約のネットワークパラメータ設定への変換に使用される。]
[0048] 上述したこのような様々な構成はさらに、メモリを有するプロセッサに使用される機械によって読み取り可能な媒体を具現化するために見ることができる。機械によって読み取り可能な媒体は、一又は複数のＱｏＳ要件を一又は複数のパラメータ値として表す情報システムのクライアントからのＱｏＳメッセージをプロセッサに受信させる命令を含むことができる。機械によって読取可能な媒体はまた、クライアントとの一又は複数のパラメータ値に基づくサービス品質の規約をプロセッサに設定させる命令も含む。機械によって読取可能な媒体は、情報システムの一又は複数のリソースをプロセッサに規約に基づいてクライアントへ割り当てさせる命令を含む。さらに、機械によって読取可能な媒体は、受信したＱｏＳメッセージを下流のミドルウェアドメインへ伝達させる命令を含む。]
[0049] 先のＱｏＳ管理システムの構成が実行されるＳＯＡにおいては、ＩｎｆｏＢｒｏｋｅｒが異なる役割及びＱｏＳ要件のクライアントへ分化サービスを提供可能である。ＩｎｆｏＢｒｏｋｅｒはしたがって、多数の並列クライアントからの要求を満たすために、リソースのアロケーション及び利用を最適化することができる。重要度の高いクライアントは、重要度の低いクライアントよりもさらにリソースを得る又はリソースの利用においてより多くを共有する。また、上述したＱｏＳ管理システムにより、ＱｏＳ要件を保持しながら複数のミドルウェアドメイン全体のエンドポイントからエンドポイントへのメッセージの送信が可能になる。]
[0050] 前述のシステム構成は、ネットワークスループットを管理して優先度に基づく確実な情報の配信を提供するのに使用できる。リソースがオブジェクト指向法においてモデル化されているため、先の方法により、複数のミドルウェアプラットホーム全体の一貫したリソース管理及び多様なリソースアロケーションが可能になる。]
[0051] 上述したＸＭＬベースのＱｏＳ言語により、アプリケーションがＱｏＳ要件をＱｏＳ特性の様々な態様において表すのに、柔軟で拡張可能な方法が提供される。ＱｏＳサービスプロバイダにはしたがって、ＱｏＳ特性の全ての態様を単一のフレームワークに統合し処理するアーキテクチャが提供され得る。前述のシステムにおいては、情報システムのリソースはソフトウェアオブジェクトとしてモデル化され、複数のミドルウェアプラットホーム全体で多様なリソースアロケーションを提供する。タスク及びメッセージ両方のＱｏＳ特性は単一のフレームワークにおいて管理される。並列アプリケーションのＱｏＳ要件は例えば、システムミドルウェア層のＱｏＳサービスプロバイダを通して満たされる。]
[0052] リソースはそのユティリティに基づいてカテゴリーに分類され、ランタイムにおける構成が大幅に簡素化される。前述のリソースアロケーション方法はポリシーベースであってよく、簡単に修正し拡張することが可能である。本方法は、割り当てられたリソースを効果的に管理することによって、重要度の高いクライアントの遅延を重要度の低いクライアントよりも確実に短くする。構成は、ランタイムにおけるクライアントの動作がクライアントのＱｏＳ規約を施行するために変わる時に、リソースアロケーションを変えることができる。]
[0053] さらなる実施形態を下記のように請求項の書式に記載することができる：
Ａ１１ 複数の相互接続ミドルウェアドメイン内及び全体の一貫したＱｏＳレベルを有するメッセージフローを提供するサービス品質(ＱｏＳ)ブリッジであって、前記ＱｏＳブリッジは第１ＱｏＳマネージャから少なくとも１つのＱｏＳ要件を受信し、少なくとも１つのＱｏＳ要件を第２ＱｏＳマネージャへ伝播し、少なくとも１つのＱｏＳ要件を少なくとも１つのＱｏＳパラメータへ変換するように構成されており、前記ＱｏＳブリッジは、少なくとも１つのＱｏＳパラメータを受信し施行して、前記複数の相互接続ミドルウェアドメイン間のメッセージフローを容易にするために、メッセージサービスを利用する。
Ａ１２ 少なくとも１つのＱｏＳ要件が、少なくとも１つのＱｏＳポリシー及び利用可能なリソースに基づくＱｏＳ規約を含む、請求項Ａ１１に記載のＱｏＳブリッジ。
Ａ１３ ＱｏＳブリッジが、前記複数の相互接続ミドルウェアドメイン間に一貫したＱｏＳを有するエンド・エンドメッセージフローを提供する、請求項Ａ１１に記載のＱｏＳブリッジ。]
[0054] 本発明を様々な特定の実施形態の観点から説明してきたが、当業者には、本発明を請求項の精神及び範囲内で修正して実行することができることが分かるであろう。]

权利要求:

請求項1
複数の相互接続ミドルウェアドメイン内及び全体で、一貫したサービス品質「ＱｏＳ」レベルを有するメッセージフローを提供するための、情報システム・リソースを管理する方法であって：少なくとも１つのＱｏＳ要件を表す第１ＱｏＳマネージャ（４２６、５６４）からＱｏＳメッセージを受信し；少なくとも１つのＱｏＳ要件を、複数のミドルウェアドメイン（４０４、４０６）を通信可能に連結するメッセージサービス（４３２）に特有の少なくとも１つのパラメータに変換し；メッセージフローを受信するために、第１ミドルウェアドメイン（４０４）とメッセージサービスの間にクライアント接続を作成し；ＱｏＳメッセージを第２ミドルウェアドメイン（４０６）へ送信し；メッセージフローを送信するために、メッセージサービスと第２ミドルウェアドメインの間にクライアント接続を作成することを含む方法。
請求項2
少なくとも１つのＱｏＳ要件に基づくサービス品質のために、第１ＱｏＳマネージャとクライアント（２４、４０８）の間に第１規約を設定することをさらに含み、第１ＱｏＳマネージャからのＱｏＳメッセージの受信が、第１ＱｏＳマネージャから第１ＱｏＳ規約を受信することを含む、請求項１に記載の方法。
請求項3
第１ＱｏＳ規約に基づく情報システムとのクライアントの相互作用の管理と、リソースアロケーションポリシーに基づくシステムのリソースの割り当てのうちの少なくとも１つをさらに含む、請求項２に記載の方法。
請求項4
ＱｏＳメッセージの第２ミドルウェアドメインへの送信が、リソースアロケーションポリシー（４４６、５３０）にしたがったＱｏＳメッセージの変換を含む、請求項３に記載の方法。
請求項5
ＱｏＳメッセージの送信が、ＱｏＳメッセージに基づく第２規約の設定と、第２規約に基づくメッセージサービスと第２ミドルウェアドメインとの相互作用の管理をさらに含む、請求項１に記載の方法。
請求項6
情報システムが、サービス指向アーキテクチャ「ＳＯＡ」を含み、前記方法がクライアントによって呼び出されるサービスとして実施される、請求項１に記載の方法。
請求項7
メッセージを発行若しくは購読又はタスクの実行を要求する準備をしている複数のＱｏＳマネージャから複数のＱｏＳメッセージを受信して、ＱｏＳメッセージに表された要件に基づくＱｏＳについて、ＱｏＳマネージャと規約を設定することをさらに含む、請求項１に記載の方法。
請求項8
第１ＱｏＳマネージャからのＱｏＳメッセージの受信が、第１ＱｏＳマネージャからＱｏＳメッセージが配信されない場合にデフォルトＱｏＳメッセージを適用することをさらに含み、メッセージフローを受信するために、第１ミドルウェアドメインとメッセージサービスとの間にクライアント接続を作成する時に、デフォルトＱｏＳメッセージが少なくとも１つのＱｏＳ要件を表す、請求項１に記載の方法。
請求項9
メッセージフローをサブスクライバ（３４）において受信することをさらに含む、請求項１に記載の方法。
請求項10
少なくとも１つのプロセッサによって実行される少なくとも１つの第１ミドルウェアソリューションと第２ミドルウェアソリューションを含む情報システムにおいてＱｏＳを管理するサービス品質「ＱｏＳ」管理システムであって：少なくとも１つのＱｏＳパラメータを表すＱｏＳメッセージが前記情報システムのクライアントから受信されるように、前記少なくとも１つのプロセッサで実行される第１ＱｏＳマネージャ（４２６、５２４）；ＱｏＳメッセージが前記第１ＱｏＳマネージャから受信されるように、前記少なくとも１つのプロセッサで実行されるＱｏＳブリッジ（４３０、５７０）；及び、前記ＱｏＳブリッジからのＱｏＳメッセージが前記第２ＱｏＳマネージャによって受信され、前記情報システムのサブスクライバへ送られて、クライアントとサブスクライバの間に一貫したＱｏＳを有するエンド・エンドメッセージフローを提供するように、前記少なくとも１つのプロセッサで実行される第２ＱｏＳマネージャ（４２８、５６６）を含むＱｏＳ管理システム。
請求項11
第１ミドルウェアソリューションからのメッセージフローが、前記ＱｏＳブリッジによって促進されて、前記メッセージサービスにおいて受信されるように、前記少なくとも１つのプロセッサで実行されるメッセージサービス（４３２）を利用する、請求項１０に記載のＱｏＳ管理システム。
請求項12
前記ＱｏＳブリッジが、受信されたＱｏＳメッセージの前記第２ＱｏＳマネージャへの伝達、及びブリッジポリシーを使用して、受信されたＱｏＳメッセージの前記メッセージサービスに特有の一連のＱｏＳパラメータへの修正のうちの少なくとも１つをさらに行う、請求項１１に記載のＱｏＳ管理システム。
請求項13
前記第１ＱｏＳマネージャが、前記第１ＱｏＳマネージャとクライアントとの間に第１規約をさらに設定する、請求項１０に記載のＱｏＳ管理システム。
請求項14
前記ＱｏＳブリッジが：前記第１ＱｏＳマネージャから前記第１規約を受信し；少なくとも１つのＱｏＳパラメータに関して少なくとも１つのシステムポリシーをチェックして、少なくとも１つのＱｏＳパラメータに表されたクライアントの要件を満たすために、少なくとも１つのリソースを決定し；第１ＱｏＳマネージャからのＱｏＳメッセージの少なくとも１つのＱｏＳパラメータに関して少なくとも１つのシステムポリシーをチェックして、少なくとも１つのＱｏＳパラメータを決定し、少なくとも１つのＱｏＳパラメータに基づいて第２ＱｏＳマネージャへＱｏＳメッセージを送信することのうちの少なくとも１つを行う、請求項１３に記載のＱｏＳ管理システム。
請求項15
前記第１ＱｏＳマネージャ、前記ＱｏＳブリッジ、及び前記第２ＱｏＳマネージャのうちの少なくとも１つが、ポリシー及びＱｏＳメッセージのうちの少なくとも１つに基づいて前記情報システムの少なくとも１つのリソースをクライアントへ割り当てる、請求項１０に記載のＱｏＳ管理システム。